The Open Mobile Alliance (OMA), a mobile standard organization, includes a plurality of working groups according to technologies, one of which is a device management (DM) working group. The DM working group is in the process of establishing a service standard using a DM protocol between a device management server (DM server) and a device management client (DM client) in order to provide optimum service to mobile terminals in a wireless environment. That is, the DM working group is in the process of developing a device management standard by which a wireless operator or service provider can manage firmware, software, parameters, schedules, etc. of a mobile terminal while wirelessly communicating with the mobile terminal.
A DM server and a DM client have data to be shared between them, wherein the data is called a management object (MO). The MO defines parameters which must be shared between a DM server and a DM client, in a tree-type data structure. There are various MOs, one of which is a Trap MO.
When a specific event or trap is issued from a DM client, the Trap MO functions to inform such an event issue to a DM server or to other MOs in the mobile terminal. Accordingly, when a specific event is issued, the DM server or other MOs in the mobile terminal are notified of the event issue through the Trap MO, and perform operations established in themselves.
The Trap MO includes either an ID of the DM server or an MO identifier (hereinafter, referred to as an “MO URI”) of a different MO, which is to be notified of the event issue, wherein the operation of registering a DM server ID or an MO URI in the Trap MO may be performed by the DM server.
FIG. 1 is a flowchart illustrating a conventional procedure for registering a notification target MO in a Trap MO of a DM client.
As shown in FIG. 1, when a DM server 100 requests a DM client 200 to register a notification target MO (hereinafter, referred to as an “MO1”) in step 1, the DM client 200 determines if the DM server 100, which has made the request, has registration request authority in step 2. When the DM server 100 has no registration request authority, the DM client 200 transmits a registration error message to the DM server 100 in step 4. When the DM server 100 has registration request authority, the DM client 200 registers an MO1 URI in a Trap MO in step 3, and transmits a registration confirmation message to the DM server 100 in step 5.